System and method to manage a workflow in delivering healthcare

ABSTRACT

An example method to assign a plurality of resources to patient progressing through a workflow of events includes tracking a first property of a first resource, tracking a second property of a second resource, calculating a first set of bids for the first and second resources based on the respective first and second properties, assigning one of the first resource or the second resource to the slot in the workflow of events based on the first set of bids, introducing a third resource and tracking a third property of the third resource and calculating a second set of bids for the first, second and third resources based on the respective first, second and third properties, and reassigning one of the first resource, the second resource or the third resource to the slot in the workflow of events based on the second set of bids.

RELATED APPLICATIONS

This patent arises from a continuation of U.S. application Ser. No.11/972,878, which was filed on Jan. 11, 2008, and is hereby incorporatedherein by reference in its entirety.

BACKGROUND

The subject herein generally relates to a system and method to manageprogression of a patient through a workflow, and in particular, theworkflow is a healthcare procedure.

Hospitals and other medical facilities (e.g., imaging centers,cardiology treatment centers, emergency rooms, surgical suites, etc.)include various workflows to deliver diagnosis or treatment to admittedpatients. These workflows are comprised of events that employ variousresources, such as imaging rooms, physicians, nurses, radiologists,cardiologists, clinicians, technicians, or transcriptionists. Theseworkflows are often unstructured and non-linear in nature due to complexconditions that dynamically evolve at any point in time of the workflow.

Known systems and methods to manage patients through these workflowsdelivered at healthcare facilities are generally static andnon-adaptive. These known systems generally rely on past data and lineardesign assumptions to manage workflows (e.g., diagnostic imaging,cardiac treatment, etc.). As a result, these known systems and methodsare generally inflexible or unresponsive to non-linear changes or eventsthat increase the likelihood of chaos due to complex conditions thatevolve in real time beyond the original linear design. Examples ofparameters to measure a quality of service or efficiency of workflowsinclude, but are not limited to, patient wait times, procedureturn-around times, resource utilization, etc. For example, increasingprocedure turn-around times can increase underutilization of resources(e.g., an imaging room sitting idle).

BRIEF SUMMARY

Thus, there exist a need for a system and method for real-timemedical/clinical workflow management and optimization. The system needsto be multi-variant to address variation demand and urgency, diverseprocedure goals, custom workflows without standard work times, unusedcapacity, excess waiting by patients, and delay of critical decisionmaking due to lack of critical information. The above-mentioned problemsand needs are addressed by the subject matter described herein in thefollowing description.

According to one embodiment, a system to manage progression of aplurality of patients through a workflow of events that employs aplurality of resources is provided. The system comprises at least onesensor operable to track at least one property of more than one of theplurality of resources; and at least one processor in communication withthe at least one sensor. The at least one processor is operable toexecute a plurality computer readable program instructions generallyrepresentative of the steps of calculating a bid of the more than one ofthe plurality of resources relative to one another directed to a slot inthe schedule of workflow of the at least one patient, the bid dependenton the at least one tracked property of the more than one of theplurality of resources, and assigning one of the more than one resourceto the slot in the schedule of workflow of the least one patientdependent on a comparison of the bid of the more than one resourcerelative to one another.

According to another embodiment, a method to manage progression of atleast one patient through a workflow of events that employs a pluralityof resources, comprising tracking at least one property of more than oneof the plurality of resources; calculating a bid of the more than one ofthe plurality of resources relative to one another directed to a slot ina schedule of the workflow of the least one patient, the bid dependenton the at least one tracked property of the more than one resources; andassigning one of the more than one resource to the slot in the scheduleof workflow of the least one patient dependent on a comparison of thebid of the more than one resource relative to one another.

According to yet another embodiment, a dashboard to manage progress atleast one patient through a workflow of events in delivering healthcareis provided. The dashboard comprises an illustration of an identifier ofat least patient; and an illustration of an identifier of each of themore than one resources designated to be utilized on the patientprogressing through the events of the workflow, the illustrations ofidentifiers of the more than one resources arranged according to anorder of value of a bid of each of the more than one resources directedto utilization on the at least one patient in the workflow.

Various other features, objects, and advantages of the disclosure willbe made apparent to those skilled in the art from the accompanyingdrawings and detailed description thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic overview of an embodiment of system to manage aworkflow.

FIG. 2 is a flowchart illustrating an embodiment of a method to managethe workflow with the system of FIG. 1.

FIG. 3 is a schematic diagram illustrating another embodiment of asystem to manage a workflow in a clinical environment.

FIG. 4 is a block diagram illustrating another embodiment of a system tomanage a workflow to schedule a patient to undergo medical imaging.

FIG. 5 is a pictorial illustration of another embodiment of a system tomanage a workflow in a clinical environment.

FIG. 6 is a flowchart illustrating another embodiment of a method ofmanaging a workflow to schedule patients for a clinical procedure.

FIG. 7 is illustrative of an embodiment of a dashboard operable toreport an output of the system at any point in time of a patientprogressing through the workflow.

FIG. 8 is illustrative of another embodiment of a dashboard operable toreport an output of the system at any point in time of a patientprogressing through the workflow.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings that form a part hereof, and in which is shown byway of illustration specific embodiments that may be practiced. Theseembodiments are described in sufficient detail to enable those skilledin the art to practice the embodiments, and it is to be understood thatother embodiments may be utilized and that logical, mechanical,electrical and other changes may be made without departing from thescope of the embodiments. The following detailed description is,therefore, not to be taken as limiting the scope of the disclosure.

FIG. 1 illustrates a schematic diagram of an embodiment of a system 100to manage a patient 105 through a workflow having an increasedprobability or likelihood toward chaos due to complex, non-linearconditions. The complex conditions can evolve in general real timebeyond an original or predetermined design before the start of theworkflow.

An embodiment of workflow as herein used can generally be defined as anembodiment of a sequence of tasks or states or steps or events (e.g.,physician examination, laboratory tests, acquire electrocardiogram (ECG)data, etc.) that may or may not employ use or operation or involvementof a series of resources 110, 112, 114 to deliver a defined outcome(e.g., treatment of the patient 105 for chest pain, broken arm, trauma,illness, etc.). The number of resources 110, 112, 114 can vary. Anembodiment of the resources 110, 112, 114 can be operable to interactwith each other in general real-time, as well as be operable toestablish a logical relationship among one another. The resources 110,112, 114 may be included at the beginning of the workflow or in generalreal time during or between the events or steps of the workflow. Oneembodiment of the resources 110, 112, 114 include a physician 110, animaging or scanning system 112, and a laboratory device 114. Yet, theresources 110, 112, and 114 can include test laboratories, etc. or anyimaginable element involved in treatment or study of the patient 105.

An embodiment of each of the series of resources 110, 112, 114 and thepatient 105 can be assigned with at least one property 116, 118, 120,121, respectively. The type and number of properties 116, 118, 120, 121can vary. The properties 116, 118, 120, 121 may be static so as toremain the same throughout the workflow. The properties 116, 118, 120,121 can also be dynamic with an ability to change with time. Forexample, an “elapsed time” can be one of the properties 116, 118, 120,121. Generally, the properties 116, 118, 120, 121 are predeterminedprior to or at the beginning of the workflow. However, the properties116, 118, 120, 121 can be identified or added while executing theworkflow in general real-time. For example, one or more properties 116,118, 120, 121 can be added to track a chaos or unpredictability of theavailability of the resources 110, 112, 114 or events in the workflow.Another example of tracked properties 116, 118, 120, 121 include thecapacity of technicians, capacity of physicians, capacity of facility,or any element involved in the workflow. Another example of the workflowin the clinical environment includes an investigational study whereresources 110, 112, 114 include an ultrasound system 110 and anultrasound operator 112 to perform a cardiac exam, where the ultrasoundoperator's skill and knowledge of anatomy is employed to gather themedical information from or for the study. In each case, wait times andlists of the series of patients 105 can vary in a non-linear manner.

An agent 122, 124, 126, 127 generally includes computer-readable programinstructions in or not in combination with one or sensor devices (e.g.,clocks, timers, blood pressure monitors, electrocardiogram (ECG)monitors, temperature monitors, etc.) created to correlate with eachresource 110, 112, 114 or the patient 105, respectively. Each agent 122,124, 126, 127 is generally operable to track or identify changes in theproperties 116, 118, 120, 121 associated with each of the resources 110,112, 114 and the patient 105, respectively. The agents 122, 124, 126,127 can be created upon introduction or creation of the respectiveresource 110, 112, 114 or patient 105 into the workflow. The agents 122,124, 126, 127 are generally operable to communicate or collaborate ingeneral real-time with one another, as well as with the respectiveresources 110, 112, 114 or patient 105. FIG. 1 shows the agents 122,124, 126, 127 located at the respective resource 110, 112, 114 or thepatient 105, respectively. Yet, it should be understood that one or moreof the agents 122, 124, 126, 127 can otherwise be located at a centralcontroller or server 128.

One embodiment of the agents 122, 124, 126, 127 are configured to sense,detect, or track a presence and an awareness. Presence generally refersto an ability of the agent 122, 124, 126, 127 to express or communicatea current state of activity (e.g., available, partially in-use, fully inuse, etc.) of itself to other agents 122, 124, 126, 127 in the system100. For example, presence can include identifying or detecting whetheranother particular agent(s) 122, 124, 126, 127 is available, and ifavailable, to communicate or collaborate its availability to theparticular agent(s) 122, 124, 126, 127. Awareness generally refers to anability of the agent 122, 124, 126, 127 to sense a presence of otheragents 122, 124, 126, 127 or resources 110, 112, 114 or patients 105 inthe system 100. For example, awareness can include an ability to trackthe activities of other resources 110, 112, 114 or patients 105 in theworkflow. The combination of presence and awareness enables each agent122, 124, 126, 127 to initiate a communication with one another toidentify or calculate a length of time to get a response from oneanother. Awareness also allows the agent 122, 124, 126, 127 initiating acommunication to make decisions about mode of communication (e.g.,route, wireless versus wired connection, etc.) to establish contact. Anability to express or communicate the presence and leverage theawareness allows the agents 122, 124, 126, 127 to initiatecommunications with one another and to respond to communications fromother agents 122, 124, 126, 127.

Examples of agents 122, 124, 126, 127 can receive/communicate patientdata, receive/communicate requests for a work order and a report status,receive/communicate patient notifications to report for an event or stepin the workflow (e.g., testing, imaging), and receive/communicateproblems. Examples of agents 122, 124, 126, 127 are also operable tocontact respective physicians waiting for critical patient informationusing an identified best mode of communication (e.g., beeper, hometelephone, email, cellular phone, text message, etc.). Additionally,physicians 110 or patients 105 can communicate via computer messagingsystems or other known type of input (e.g., keyboard, touch-screen,voice recognition, etc.) with the agents 122, 124, 126, 127 in theworkflow community to gain access to information and collaborate withagents 122, 124, 126, 127 at any given point in time of the workflow.

An embodiment of the agents 122, 124, 126, 127 can be configured tocollaborate in calculating or assigning a priority status 129 of eachpatient 105 to one or more available the resource 110, 112, 114 employedin the workflow relative to other patients 105. Vice versa or inaddition, the agents 122, 124, 126, 127 can be configured to collaboratein calculating priority statuses 130, 132, 134 of each resource 110,112, 114 to each patient 105. Of course, the number of priority statuses129, 130, 132, 134 can vary with the number of resources 110, 112, 114and patients 105. The priority statuses 129, 130, 132, 134 are createdor assigned via the collaboration or communication of the agent 122,124, 126, 127. The agents 122, 124, 126, 127 collaborate with oneanother to calculate or create the priority status the patient 105 foreach resource 110, 112, 114 dependent on miscellaneous factors,including but not limited to, the tracked properties 116, 118, 120, 121of all the resources 110, 112, 114 and the patients 105 in the system100 tracked in general real-time or any given point in time of theworkflow. A technical effect of the priority status 129, 130, 132, 134is to generally define the criticality of each patient 105 relative toone another with respect o each of the resources 110, 112, 114 at anygiven point of time, or vice versa, the priority of each resource 110,112, 114 to each patient 105 at any point in time. The agents 122, 124,126, 127 can dynamically re-assign or re-set the priority statuses 129,130, 132, 134 at generally any point in time of the workflow. If a newresource is added in the workflow, a new agent is assigned or createdfor that new resource, where the new agent tracks the one or moreproperties of the new resource with time and interacts or collaborateswith other agents 122, 124, 126, 127 to calculate the priority status ofeach relative to one another.

For example, the agents 122, 124, 126 can track the number of uses oroperations of the resources 110, 112, 114 of the system 100. Afterdetecting a predetermined number of uses, the agents 122, 124, 126 canautomatically communicate a signal to other agents 122, 124, 126, 127that one or more of the resources 110, 112, 114 is not available (e.g.,maintenance, end of life, etc.), or create a purchase order or leaserequest for its replacement resource 122, 124, 126. The series of agents122, 124, 126, 127 can include, or the system 100 can further include,an additional agent having a general ability to supervise or track allof the resources 110, 112, 114 and patients 105 in the workflow, andidentify or detect for errors (e.g., critical patient needs or wait timenot being met in a timely manner).

The embodiment of the workflow management system 100 further includes anassessment or bidding engine 140. Although the bidding engine 140 isillustrated at the central server or computer 128, it should beunderstood that the bidding engine 140 can be located at any of theresources 110, 112, 114 of the system 100. An embodiment of the biddingengine 140 is generally operable to create or calculate or generate anassessment index or bid. One embodiment of the bid is a value indicativeof a priority status of each patient 105 relative to one anotherdirected to a slot in the schedule of operation or utilization of one ormore of the resources 110, 112, 114. Vice versa, the assessment index orbid can include a value representative of a value of priority status ofallocation of each resource 110, 112, 114 to each patient 105 relativeto the other resources 110, 112, 114. Another embodiment of theassessment index or bid is generally representative of a value ofpatient risk or criticality of if not to receive treatment by or haveaccess to (e.g., a slot in the schedule) one or more of the resources110, 112, 114 relative to other patients 105. The more critical a healthcondition of the patient 105 or the greater a wait time of the patient105 generally results in a greater value of patient risk or criticalityrelative to others. Yet another embodiment of the assessment index orbid generally represents a value or amount indicative of an availabilityeach resources 110, 112, 114 (e.g., readiness to utilize (clean, not duefor maintenance, not failed), location relative to patient, etc.)relative to the others as to be employed on each patient 105 in one ormore steps in the workflow.

The bidding engine 140 generally calculates or creates each biddependent on a series of factors, including the current priority status129, 130, 132, 134 assigned or created for each patient 105 or eachresource 110, 112, 114, and a wait time of each patient 105 for eachresource 110, 112, 114. In an example, the bidding engine 140 calculatesthe bids in general real-time (e.g., at any point in time) dependent onthe priority status of each patient 105, which is calculated atregistration and updated or created with detected changes in theproperties 116, 118, 120 of each of the resources 110, 112, 114 astracked and communicated by the agents 122, 124, 126, respectively.

The bidding engine 140 can communicate with the agents 122, 124, 126 toreceive the priority statuses 130, 132, 134 to each resource 110, 112,114. Alternatively, the bidding engine 140 can collaborate incombination with the agents 122, 124, 126 to create or calculate thepriority status of each resource 110, 112, 114 to each patient 105. Oncethe bidding engine 140 receives or creates the priority statuses 130,132, 134, the bidding engine 140 calculates a bid dependent on a set ofbidding policies for each available resource 110, 112, 114 employed inthe workflow. Dependent on the value of each of the bids and the numberof patients 105, the bidding engine 140 also calculates or adjusts theslots in the schedule to use or access each resource 110, 112, 114. Thebidding engine 140 can dynamically update or change or recalculate(e.g., continuously or periodically) the schedule of the resources 110,112, 114 with changes in their priority statuses, which can becorrelated to or dependent on changes in the properties 116, 118, 120(e.g., downtime for failure or routine maintenance, utilization, etc.)of each of the resource 110, 112, 114, respectively, at any point intime in the workflow.

The system 100 can also include a broker 150 in communication orcombination with the bidding engine 140. An embodiment of the broker 150generally evaluates which of the series of patients 105 holds thehighest bid to each of the resources 110, 112, 114. A technical effectof the broker 150 is generally operable to optimize (e.g., reduceoverall wait time of patients, allocate resources for greatestutilization, etc.) the workflow dependent on a series of factors,including the bids calculated or created for each resource 110, 112,114, the availability of resources 110, 112, 114, and the availableviable options. The broker 150 can be located with any of the resources110, 112, 114 or at the central server 128. One embodiment of the broker150 is operable or configured to change one or more properties 116, 118,120, 121 of the resources 110, 112, 114 or patient 105, respectively, orchange one or more of the bids generated by the bidding engine 140,dependent on tracked changes to the properties 116, 118, 120, 121 of thepatient 105 or to one or more of the resources 110, 112, 114. Forexample, some of the properties 116, 118, 120, 121 may becomeinsignificant with time. The broker 150 can configure or communicatewith the agents 122, 124, 126, 127 to end or discard tracking ofinsignificant properties at any point in time.

Another embodiment of the broker 150 is generally operable or configuredto alter, modify, suggest, or cancel steps or events in the workflowdependent on the priority status 130, 132, 134 of each patient 105 tothe one or more resources 110, 112, 114. Assume, for sake of example,that the agent 127 of the patient 105 in a clinical workflow tracks theproperty 121 generally representative or indicative of a senior citizenof physical condition such that undergoing a treadmill test isundesired. In response to identifying or detecting this property 121,the broker 150 can modify the workflow to skip the step of the treadmilltest in the workflow. The broker 150 can be further configured to changethe schedule or priority status 130, 132, 134 to the otherwise scheduledresources 110, 112, 114 according to the detected change in theproperties 116, 118, 120, 121.

Assume, for another sake of another example, that resource 114 employedin the workflow (e.g., clinical procedure) is a scanner, and that thescanner agent 124 has detected or identified that the tracked scannerproperty 118 is indicative that the scanner 112 has failed or isoverloaded or otherwise generally unavailable. The broker 150 isgenerally operable to re-calculate bids of each patient 105 in view ofalternative options to provide treatment to the patient 105 at a minimalcost. For example, the broker 150 can locate another resource (e.g.,search inventory) having the same or similar function as the scanner 114that is available for use (e.g., identify another imaging room withanother available scanner). The property 118 being tracked by thescanner agent 124 can include a capacity of the scanner 112, and anotherproperty 121 tracked by the agent 127 can include a tracked wait time touse the scanner 112. The updates or changes to the tracked values orstatuses of these properties 116, 118, 120, 121 directed to capacity orwaiting time can be communicated to the bidding engine 140 or broker150. In response, the broker 150 can re-create or adjust the schedule ofeach respective patient 105 or resource 110, 112, 114, the broker 150can change one or more bidding policies that constrain or defineboundary conditions of the bidding engine 140, or the broker 150 canchange the workflow to skip the event or step involving the scanner 112,or the broker 150 can create a purchase order or lease request for anadditional resource similar in function to the scanner 112.

An embodiment of the broker 150 can be further configured to modify anoperational profile of one or more of the resources 110, 112, 114 or thepatient 105. An embodiment the broker 150 can also be configured tochange the measured values or the tracking of the properties 116, 118,120, 121 in relation to time or the workflow. For example, if the waittime of any one patient 105 exceeds more than the maximum set time, thebroker 150 can change the one or more properties 116, 118, 120, 121 of,or the bid calculated for, each of the patients 105 so as to selectivelycause an increase or decrease in the priority status of any one patient105 exceeding in wait time relative to other patients 105. To accomplishthis, upon detecting the wait time of one patient 105 to exceed thethreshold of wait time, the broker 150 calculates the bid of the onepatient 105 tracked that exceeds in wait time with a bid of valuegreater than, or calculate the bid value to be an order or more ofmagnitude greater than, the bid value of any other patient 105.

For example, assume the resource 112 is generally representative of abuyer, and resource 114 is generally representative of a supplier. Thesuppliers 114 provide various services, and the buyers 112 avail to theservice of the suppliers 114. The suppliers 114 and the buyers 112 haverespective properties 118, 120 and the agents 124, 126 track or measurethe properties 118, 120 or changes thereto at any instant of time. Theagents 124, 126 collaborate or communicate with one another to calculateor create a priority status of each buyer 112 and supplier 114 relativeto one another. The bidding engine 140 receives the priority statusesfor the buyers and suppliers 112 and 114, and dependent thereon createsa schedule for the services provided by the suppliers 114 to avail tothe buyers 112. Accordingly, rather than being driven solely by the nextsequential task, the system 100 is also operable to schedule and managethe workflow according to other factors, including a capacity of theresources 112, 114 employed in the workflow relative to one another.

The system 100 is generally operable via the agents 122, 124, 126, 127to track the dynamics of individual or population of patients 105 overtime and their respective needs and demands on other resources 112, 114.Objective functions of the system 100 include increasing an “efficiency”from a standpoint of the healthcare or service provider, and increase an“equity” (e.g., wait time) from a standpoint of the patient 110 in theworkflow managed by the system 100. The bidding engine 140 and broker150 are operable to communicate or collaborate with one another and theagents 122, 124, 126, 127 to create or adjust the bidding policies orthe workflow so as to select the optimal bidding policy for theworkflow. The system 100 is generally operable in continuous time andcontinuous space.

An embodiment of the controller 128 is connected in communication witheach of the agents 122, 124, 126, 127, bidding engine 140 and broker150. An embodiment of the controller 128 includes a memory or database155 generally operable to receive updated values or measurements oftracked properties 116, 118, 120, 121 on a continuous or periodic basisof the resources 110, 112, 114 or patient 105, respectively, receive newproprieties with respect to new resources or additional patients 105,bids of each patient 105 for each of the resources 110, 112, 114 at apoint or instant of time of the workflow, a calculated schedule, etc.

The controller 128 can also include a processor 160 generally configuredto execute program instructions store in the memory 155. Although thememory 155 and processor 160 are shown at the computer 128, it should beunderstood that an embodiment of the agents 116, 118, 120, 121, thebidding engine 140, or the broker 150 described above can each includeprocessors in communication with memory or storage medium ofcomputer-readable program instructions located at one of the resources110, 112, 114.

An embodiment of the system 100 may further include a series of a meansof sensing or sensors 170, 172, 174, 176 operable to track a location ofeach patient 105 or resource 110, 112, 114, respectively, with respectto a reference or to one another. An embodiment of each sensor 170, 172,174, 176 is operable to communicate a location of each patient 105relative to a predetermined reference. The sensors 170, 172, 174, 176can be operable to track in coordinates, or by room or floor number,etc. The sensors 170, 172, 174, 176 can be in wireless communicationwith a receiver 180 connected in communication with the controller 128.An embodiment of the sensors 170, 172, 174, 176 can include acombination of transmitters in electromagnetic communication withreceivers, transmitters in communication with receivers directed toradio frequency identification (RFID), optical sensors, globalpositioning system (GPS) in communication with satellite(s), etc. orother position measuring or locating technology known in the art orcombination thereof.

FIG. 2 includes a schematic flow diagram illustrating an embodiment of amethod 200 of operation of the system 100 to dynamically manage (e.g.,scheduling) the patient(s) 105 through events of the workflow thatemploys the series of resources 110, 112, 114. It should also beunderstood that the sequence of the acts or steps of the method 200 asdiscussed in the foregoing description can vary. Also, it should beunderstood that the method 200 may not require each act or step in theforegoing description, or may include additional acts or steps notdisclosed herein. It should also be understood that one or more of thesteps of the method 200 can be represented as computer-readable programinstructions for execution by one or more processors of the agents 122,124, 126, 127, the bidding engine 140, the broker 150, or the centralserver 128.

Step 210 includes assigning or identifying the properties 116, 118, 120,121 to each of the patients 105 or resources 110, 112, 114 identified asemployed in the workflow. An embodiment of step 210 includes identifyingvarious steps or events involved in the workflow, and identifying theresources 110, 112, 114 and patients 105 involved in the steps or eventsof the workflow. The patients 105 or resources 110, 112, 114 andrespective properties 116, 118, 120, 121 can also be identified or addedat any point or instant in time of the workflow.

Step 220 includes identifying or creating the agent 122, 124, 126, 127corresponding to each resource 110, 112, 114 and the patient 105. Anembodiment of the agents 122, 124, 126, 127 are configured to track atleast one property 116, 118, 120, 121 (e.g., dynamic property) of thepatients 105 or resources 110, 112, 114 at any point in time of theworkflow. The agents 122, 124, 126, 127 are further configured to trackand communicate measurements of the tracked properties 116, 118, 120,121 relative to one another and any changes thereto in generallyreal-time (e.g., continuously or periodically updated through workflow).The agents 122, 124, 126, 127 are further configured to collaborate orcommunicate the tracked status or values of the properties 116, 118,120, 121 with one another via general direct or indirect interaction orcommunication among the agents 122, 124, 126, 127 or the resources 110,112, 114 involved in the workflow.

Step 230 includes calculating or creating the priority status of eachpatient 105 to each resource 110, 112, 114. Vice versa, step 230 caninclude calculating or creating the priority status of each resource110, 112, 114 to each patient 105. One embodiment of step 230 includeseach agent 122, 124, 126, 127 tracking different properties 116, 118,120, 121 of the resources 110, 112, 114 or patient 105 to which it isassociated. The agents 122, 124, 126, 127 can also be operable tocommunicate the tracked values or states of the properties 116, 118,120, 121 of the respective resources 110, 112, 114 or patient 105relative to one another. By collaborating or communicating with oneanother or the resources 110, 112, 114 or patient 105, the agents 122,124, 126, 127 calculate or assign or identify a priority status of thepatient 105 to each resource 110, 112, 114 relative to other patients105.

Step 240 includes the bidding engine 140 calculating the bid of eachpatient 105 to each of the resources 110, 112, 114, or vice versa,calculating a bid of each resource 110, 112, 114 to each patient 105, ina general bidding process, dependent on the priority statuses calculatedin step 230. The bidding engine 140 generally co-ordinates this biddingprocess for each of the one or more events of the workflow. Oneembodiment of the bidding engine 140 calculates the bid of each patient105 to each resource 110, 112, 114 depending on a series of factors orbidding policies, including but not limited to, the received prioritystatus of the patient 105 as calculated by each agent 127, capacity ofthe resources 110, 112, 114 or workflow, a wait time of any individualpatient 105, and an availability or status of utilization (e.g., clean,due for maintenance, failed condition, inventory, in use, etc.) of theresources 110, 112, 114 that can limit or place a boundary condition onthe bidding process, and a sequence of the workflow. For example, thebidding engine 140 can calculate or simulate a plurality of the possiblecombinations of allocations of resources 110, 112, 114 to be employed inthe workflow per the patients 105 in the workflow, and calculate one ofthe plurality of possible or candidate combinations that best optimizes(e.g., minimum patient wait time, maximum throughput capacity, lowestcost, etc.) the workflow.

Step 250 includes the broker 150 calculating or comparing bids generatedby the bidding engine 140 so as to allocate or assign each of thepatients 105 to each of the slots in the schedule of the resources 110,112, 114, or vice versa, the allocation of the resources 110, 112, 114to the schedule of each of the patients 105. The broker 150 may alsoalter, modify, suggest, or cancel one or more events in the workflow viatracking of one or more properties 116, 118, 120, 121 of the resources110, 112, 114 or patient 105 in relative to time and the workflow, orchange the bids of one more patients 105 or resources 110, 112, 114dependent on updated changes to tracked data of one or more properties116, 118, 120, 121.

FIG. 3 illustrates an embodiment of a system 300 to manage a workflow ina clinical environment, similar to the system 100 described above. Anexample of workflows in a clinical environment includes a nuclearmedicine cardiac study comprised of a succession of steps, and potentialwait times between each phase of the study.

The workflow requested by a patient 310 can include the followingresources: a physician 312, clinician 314, technician 316, facility 318,remote server 320, a medical equipment or device 322, and a clinicalequipment or device 324. Of course, the types and number of resources312, 314, 316, 318, 320, 322, and 324 can vary. Properties identified orassigned to be tracked for each patient 310 at the time of admission orregistration can include a patient priority classification as a chronicversus critical condition, an ability to exercise, a predicted stresstest time for cardiac evaluation, weight, etc. in accordance toinformation provided by the patient 310 in a simple self-assessmentquestionnaire, similar to the properties 116, 118, 120, 121 describedabove. The properties can also include a liver clearance time or otherproxies calculated in the case of a Nuclear Medicine study workflow.

Agents 325, 327, 329, 331, 333, 335, 337, 339, 341 can be created totrack the one or more dynamic properties of each respective resources310, 312, 314, 316, 318, 320, 322, 322, 324. An embodiment of thepatient agent 325 tracks different properties of the patients 310 towhich it is associated, and calculates a representative current state ofactivity of the patient 310. The patient agent 325 is in communicationwith other agents 327, 329, 331, 333, 335, 337, 339, 341 of the system300. The agents 325, 327, 329, 331, 333, 335, 337, 339, 341 interact orcommunicate with one another to calculate a priority status of patient310 to each of the resources 312, 314, 316, 318, 320, 322, 322, 324relative to other patients 310 admitted to the workflow. The patientagents 325, 327, 329, 331, 333, 335, 337, 339, 341 may themselvescalculate each priority status or in combination with the help of theserver 335. The agent 325 can track the dynamic properties on an as-needbasis, period basis, or continuously through the workflow. For example,if the property of the patient 310 is classified in critical condition,the agent 325 can track the patient's blood pressure every five minutes,and this time interval can adjust with changes in the blood pressure.

The system 300 also includes a bidding engine or scheduler 344 and abroker 346, similar to the bidding engine 140, and broker 150 of thesystem 100 described above. If the property of the patient 310 isclassified or identified or calculated as an emergency or critical, theagent 325 or the bidding engine 344 may automatically calculate orassign a highest priority status to the patient 310 to push through theworkflow at a reduced time relative to other patients. In anotherexample, if a property or bidding policy is representative of a maximumwait time of the patient 310 is set for three hours prior to or duringthe workflow, then even if the patient is otherwise of a low prioritystatus based on the other properties, the bidding engine 344 mayincrease the bid so as to cause broker 346 to and schedule the patient310 ahead of others waiting for the medical or clinical device 322 or300, respectively.

An embodiment of the medical device 322 can include a processor 348generally operable to execute the functions (represented as computerreadable program instructions) of the medical device 322 or agent 339.An embodiment of the clinical device 324 can also include a processor350 that executes functions (represented as computer readable programinstructions) of the clinical device 324 or agent 341. An embodiment ofthe agent 339 created in correspondence to the medical device 322 can beoperable to track at least one property, including a failure status, ora patient handling capacity of the medical device 322. In such asituation, the agents 325, 327, 329, 331, 333, 335, 337, 339, 341 cancollaborate or communicate with one another to calculate or create apriority status of the patient 310 to each of the medical device 322 orthe clinical device 324 relative to one another.

The patient agent 325 communicates the priority status of each patient310 to the bidding engine 344. The bidding engine 344 also receives thepriority status from the agents 327, 329, 331, 333, 335, 337, 339, 341correlated to the respective physician 312, clinician 314, technician316, facility 320, medical device 322 or clinical device 324. Dependenton the received priority statuses, the bidding engine 344 calculates thebid, as described above, of each patient 310 for an opportunity to oneof the slots in the schedule of the one or more of the physician 312,clinician 314, technician 316, facility 318, remote server 320, amedical equipment or device 322, and clinical equipment or device 324,or vice versa, similar to the bidding engine 140 of the system 100described above. The bidding engine 344 can be located at either themedical device 322 or the clinical device 324 or at a server associatedtherewith.

In accordance with one or more bidding policies created for the workflowand the series of received priority statuses, the bidding engine 344 canidentify the multiple schedule combinations that employ the one or morepatients 310 in the slots of the schedule of the physician 312,clinician 314, technician 316, facility 320, medical device 322 orclinical device 324. The bid of each patient 310 to slots in theschedule of each of the physician 312, clinician 314, technician 316,facility 320, medical device 322 or clinical device 324 can be alteredat any time with a change in a tracked property, and the bidding engine344 can re-calculate the slots in the schedules accordingly so as toincrease but not overload a patient handling capacity of the physician312, clinician 314, technician 316, facility 320, medical device 322 orclinical device 324, or to reduce the wait time of each patient 310, andto increase the overall capacity of the workflow.

Another example of a property that can be tracked by one of the patientagents 325 includes a need (e.g., patient in critical or emergencycondition) to expedite a clinical study (e.g., catheter lab). Havingtracked a change in the expedited need property of the patient 310, theagent 325 can collaborate with the other agents 327, 329, 331, 333, 335,337, 339, 341 to re-calculate the priority status of each, andautomatically communicate the changes in the priority statuses to thebidding engine 140. The tracked property or measured value or status(e.g., expedited need or critical condition of the patient 310) can bemodified throughout the progression through the sequence of steps inworkflow (e.g., clinical study).

Tracked data acquired during progression through the sequence of stepscan be encoded in a patient record and stored in at the database 355(e.g., picture archival system, electronic medical record (EMR), etc.).Dependent on changes in the tracked data, the agents 327, 329, 331, 333,335, 337, 339, 341 track (e.g., continuously, periodically, etc.)communicate collaborative changes in the priority status of each to thebidding engine 344, thereby contributing to the bidding engine 344calculating bids that can push or increase the priority status of onepatient 310 relative others. In this way, the system 100 can track andschedule according to slices of events or time in the workflow of thestudy relative to changes in the criticality of the health or emergencyof each of the patients 310 and changes to the availability of patients310 or the physician 312, clinician 314, technician 316, facility 320,medical device 322 or clinical device 324.

The broker 346 is generally operable to review or re-calculate or adjustor change the assignment of one or more of the patients 310 to slots inthe schedule of each of the medical devices 322 or clinical devices 324with every completion of an event or step (e.g., a test) in theworkflow. The broker 346 can also identify or detect the patient 310with the highest priority status in accordance to the bid generated bythe bidding engine 344 relative to properties tracked by the system 300,including a capacity of the workflow, the wait-time, the time to processthrough the workflow, etc. For example, each of the bids of each of thepatients 310 to each slot in the scheduled period of operation of theresources 310, 322, 324, based on properties, current condition,applicability for the sequence of steps or events in the study or testand their derived current priority. Each patient 310 may be given anoutput device (e.g., pager, email device, etc.) or number to signaltheir assignment to the slot in the study or test. Accordingly, thebidding engine 344 in combination with the broker 346 negotiates andre-negotiates how the each patient 310 is assigned to the slots ofscheduled operation of the medical device 322 or clinical device 324 ofthe system 300, or vice versa, with changes in the tracked properties ofeach patient 310 or resources 310, 322, 324.

Further, additional bidding policies or rules or properties (e.g., withrespect to the bids or schedule of the medical device 322 or clinicaldevice 324) to track the relative wait times on each of the remainingpatients 310 so as to create or cause boundary conditions such that nopatient 310 times-out (i.e., exceeds the maximum wait time) relative toeligibility to the respective resource 310, 322, 324, such as in thecase of injection of biophysical markers (i.e. nuclear medicine), orpriority relative to a criticality of diagnostic need.

The system 300 is also operable to analyze and create a report 360(e.g., graphic display on a monitor, printout, etc.) of the trackedproperties described above to track a performance/efficiency of ortrends in the workflow relative to changes in admissions or patientpopulations, different patient groupings, changes in availability ofresources 310, 322, 324, changes in procedure, etc. Accordingly, thesystem 300 can calculate and report metrics or trends, based on acquireddata of the various properties described above, to predict or increase athroughput of the workflow relative to a patient population andgroupings over a period of time. Other metrics that can be tracked andreported by the system 300 include costs versus throughput of admission(e.g., number per day, time per patient) in the workflow.

In view of the report 360 of tracked metrics and trends in theproperties described above, the bidding policies can be altered, added,or deleted to re-define or change the rules directed to reducing thewait time of the patient 310 or to increase the availability ofresources 310, 322, 324 in the workflow. The broker 346 is generallyoperable to change bidding policies when the system 300 is stressedbeyond a normal or predetermined operating capacity that may beassociated with a demographic shift in service area for a nuclearmedicine machine that may otherwise cause lower than expectedefficiency. The broker 346 is operable to track deviations in thetracked properties or priority statuses or schedule of the physician312, clinician 314, technician 316, facility 320, medical device 322 orclinical device 324. The broker 346 is also operable to simulate ormodel the properties, priority statuses, schedule so as to calculateresulting progress of patients 310 through the workflow according to anew or change in bidding policy of the system 300. The broker 346 cancalculate the above-described simulations periodically in time, or witharrival of each patient or admission in the workflow, and track changesin the simulated values relative to realized values.

An embodiment of the system 300 can be operable to manage a workflowthat comprises several workflows among several medical facilities. Forexample, the workflow can include a workflow through a trauma unit, aworkflow through an emergency unit or room, and a workflow through anurgent care unit where there is overlap in services or steps/events ofthe workflow. According to the tracked properties of each of thepatients 310, the physician 312, clinician 314, technician 316, facility320, medical device 322 or clinical device 324, the system 100 isoperable to evaluate various combinations of scheduling the one morepatients to one or more of the patient 310, the physician 312, clinician314, technician 316, facility 320, medical device 322 or clinical device324 employed among the various workflows (e.g., trauma, emergency,urgent care) described above that is most efficient (e.g., lowestpatient wait time, largest throughput of admissions, etc.) in view ofpredicted trends calculated from historical data of the trackedproperties of the physician 312, clinician 314, technician 316, facility320, medical device 322 or clinical device 324 and of the patients 310(e.g., peak demand at particular times, etc.).

FIG. 4 illustrates another embodiment of a system 400 to managescheduling of a series of patients 410 through a workflow. An agent 415is created for each patient 410 so as to track at least several of theproperties identified for the patients 410, similar to the agents 127and 325 described above. The agent 415 can be created at the beginningof the workflow in accordance to the clinical procedure (e.g., list ofproperties are predetermined, identified, and stored for each of aseries clinical procedures for later recall per an input at theadmission of the patient 410). Various types of properties (e.g.,ability to exercise) can be measured, added or deleted from tracking bythe patient agent 415 in accordance to data acquired from self-screeningor in conducting a preliminary screening of the patient 410. Examples ofstatic properties include the patient's age, a maximum wait time, ausage of a pacemaker, etc. Examples of dynamic properties that maychange with time include an injury to the patient, blood pressure,criticality of the patient 310, change in consciousness, time limitsassociated with use of nuclear medicines or markers, etc. One or morepatient properties may be created in general real time duringprogression through the steps or events of the workflow. For example, ifthe patient 410 starts to bleed, the agent 415 may create a property totrack a degree of bleeding of the patient 410, which otherwise may nothave been defined as a property at the time of admission or prior tostart of the workflow (e.g., diagnostic imaging, clinical study,catheterization, etc.).

Assume for sake of example, the workflow of the patients 410 employs ascanner 420 used in medical imaging. An embodiment of the scanner 420includes an imager 422 (e.g., CT imaging system, PET imaging system,x-ray imaging system, MR imaging system, ultrasound imaging system,etc.) that generally performs the imaging function of the scanner 420. Ascanner agent 424 is created to track one or more properties of thescanner 420 or imager 422 employed in the clinical procedure. Forexample, the scanner agent 424 can track a capacity of the scanner 420,or a failure status of the scanner 420. The scanner agent 424 isoperable to communicate or collaborate with each of the patient agents415 directed to each of a series of patients 410, as well as otheragents (not shown) directed to other medical or clinical devices (notshown).

The embodiment of the system 400 also includes a bidding engine 426,similar to the bidding engines 140 and 344 described above. Inaccordance to the priority statuses communicated by the agents 415 ofthe patients 410 and the agent 424 of the scanner 420 (e.g., capacity),the bidding engine 426 creates or calculates a bid value of each patient410 for a slot in the schedule of the scanner 420. In creating theschedule of slots, the bidding engine 426 complies with predetermined oradded bidding policies that generally define boundary conditions of thepatient 410, scanner 420, and workflow. Alternatively, anotherembodiment of the bidding engine 426 can communicate with a schedulingdevice 428 to assign or identify each patient 410 to respective slots inthe schedule of use or availability of the scanner 420. The biddingengine 426 is operable to re-create or change the schedule in accordanceto unpredicted changes in the priority statuses that may occur as thepatients 410 progress through the workflow (e.g., clinical procedure).For example, if the patient agent 415 communicates to change one of thepatients 410 to a critical condition and associated high prioritystatus, the bidding engine 426 at any point in time of the workflow canrecalculate the bids for the one or more of the series of patients 410such that the high priority patient 410 progresses at the highestpriority status through events (e.g., schedule of the imager 422) of theworkflow in the least amount of wait time relative to the other lowerpriority status patients 410.

The system 400 can also include a broker 430 in communication with thebidding engine 426 and agents 415, 424 of the patient 410 and scanner420, respectively. If a capacity of the scanner 420 is limited, thebroker 430 may generate a message or report or purchase order thatrequests addition of another scanner 435 (shown in dashed line) to theworkflow. The broker 430 can also be operable to modify the steps orevents of the workflow. For example, the broker 430 may communicate aninstruction that causes the scanner 420 to skip one or two steps in theworkflow in response to one or more tracked properties communicated fromthe agents 415 or 424.

The system 400 is also operable to generate a report 440 of the scheduleto each patient 410 or to the technicians or clinicians involved in theworkflow. This information can be generated and reported in advance soas to reduce the preparation time of the patients 410 for the clinicalprocedure. By the time a first patient 410 completes one or more stepsof the clinical procedure, a next patient 410 can be prepped and readyaccording to the schedule. Updates to the schedule can be reported tothe patients 415 who have not yet arrived for the clinical procedure oras the changes are made by the bidding engine 426 or broker 430 inresponse to changes in the tracked properties of the patients 410 orscanner 420 during progression of patients 410 through the workflow.

In another example, assume the workflow includes steps in a process ofadministering nuclear medicine into the patient 410 to enhance imagine.If the patient agent 415 or scanner agent 424 tracks or detects a changein a patient 410 wait profile such that a number of patients 410 thathave received the nuclear medicine exceed a number of untreated patients410, then the agents 415 and 424 in communication with the biddingengine 426 are operable to modify the schedule of each patients 410 soas to cause the number of treated patients 410 to be reduced relative tothe number of untreated patients. The system 400 can also run mixedclinical populations, and use the diagnostic-test request code as partof the mechanism of the bidding engine 426.

FIG. 5 is an illustration of another embodiment of a system 500 tomanage a workflow of a patient 510 through a procedure that employs oneor more scanners 515. Assume that the system 500 collects or acquirespatient information (e.g., patient identification, blood pressure,self/pre-assessment, etc.) from each patient 510 at the time ofadmission of the patient 510 to the entity (e.g. hospital, clinic).Based on the gathered information, an agent 518 is created to track aseries of properties 520 identified for each patient 510. For example,the properties 520 can be identified according to a clinical conditionof the patient 510 and/or based on a self/pre-assessment test of thepatient 510. The system 500 includes a patient database 522 to store thedata of the tracked properties 520 (e.g., patient information such aspatient identification (ID), other gathered or tracked information, ormeasured statuses or values of the various tracked properties by theagent 518). An embodiment of the patient agents 518 can also track theproperty for a time of waiting and/or progression through the workflow.The properties 520 can also represent a maximum wait period for eachpatient, where the elapse of the maximum wait period automaticallycreates a highest priority status to the respective patient 510. Assumethat the system 500 includes a scanner agent 530 to track one or moreproperties (e.g., current capacity) of the one or more scanners 515.

The agents 518 and 530 are operable to sense the presence and awareness,as described above with respect to system 100, so as to communicate andcollaborate in general real-time with one another, and to track theproperties of the patients 510 and scanner 515 through the workflow. Oneembodiment of the patient agent 518 communicates a current state ofactivity of the patient 510 to other agents 518 of other patients 510 orto the agent 530 of the scanner 515. From the collaboration, eachpatient agent 518 identifies a priority status of each respectivepatient 510 relative to the others in each of the slots in the scheduledoperation of the scanner 515, or simply next in the scheduled operationof the scanner 515.

The scanner agent 530 can be operable to track a failure status or thepatient handling capacity or other limiting property (e.g.,unavailability of operating technician or physician or clinician) of thescanner 515. The scanner agent 530 is generally configured to establisha general real time interaction between the agents 518 of the patients510 and the scanner 515. An embodiment of the scanner agent 530 isoperable to calculate track the properties of the scanner 515 and thecapacity of the scanner 515 (e.g., the capacity of the scanner 515) at agiven point of time, and collaborate with agents 530 of other scanners515 or the agents 518 of the patients 510, and can identify a prioritystatus of the scanner 515 to each patient 510.

FIG. 6 includes a schematic flow diagram illustrative of anotherembodiment of a method 600 to manage progression of the patient 610 withchest pain through the workflow of events employing resources 110, 112,114 as shown in FIG. 1. Assume for sake of example that the illustratedembodiment of resources are as follows: a physician 110, an operatingroom 112, and a cardiac catheterization system 114.

Step 620 includes identifying the patient 105 admitted and theavailability of the resources 110, 112, 114. Of course, the number ofpatients 105 and resources 112, 114, 116 can vary. Step 620 can alsoinclude identifying the set of properties 121 (e.g., a patient handlingcapacity, a wait time, or other factor identifying an unpredictedsituation in the workflow, etc.) of each patient 105 or properties 116,118, 120 of the resources 110, 112, 114 in the workflow.

Step 630 includes creating the agents 127 operable to track theproperties 121 of the patients 610, and agents 122, 124, 126 to trackproperties 116, 118, 120 of the resources 110, 112, 114, respectively,at any point in time of the workflow. The agents 122, 124, 126, 127communicate or collaborate with each other and communicate a prioritystatus of each patient 105 or resources 110, 112, 114 to the biddingengine 140 at any given time in the workflow.

Step 645 includes the bidding engine 140 calculating the bid of each ofthe patient 105 for assignment to each slot in the schedule of operationof each resource 110, 112, 114 of the workflow, dependent on thepriority statuses communicated from the agents 122, 124, 126, 127. Asdescribed above, the bidding engine 140 can be configured to calculateor generate bids of each resource 110, 112, 114 to a slot in theschedule workflow of each of the respective patients 105.

Assume for sake of example, that the patient 105 is admitted with chestpain, and the patient agent 127 is created to track a wait time or oneor more symptoms of a heart attack, and step 620 includes identifyingthe physician 110 as the next critical resource in the workflow to treatthe patient 105. Dependent on the priority statuses received by thebidding engine 140, the bidding engine 140 calculates the bid of thepatient 105 to each slot of the schedule of the physician 110.Alternatively, the bidding engine 140 may calculate the bid of eachpatient 105 to be next in the schedule of the physician 110. Step 650includes the broker 150 calculating or assigning the patient 105 to oneof the slots in the schedule of the physician 110 dependent on the bidsgenerated by the bidding engine 140. Or in addition, the broker cancompare bids of each of the resources 110, 112, 114 so as to calculateor generate or assign each resource 110, 112, 114 to a slot in theschedule workflow of each of the patients 105.

Step 655 includes another patient (shown in dashed line and by reference665 in FIG. 6) is admitted to the workflow, and an agent 670 created forthe patient 665 tracks that the second patient 665 is in a state ofshock. Alternatively or in addition, the agent 670 can be created foreach resource 110, 112, 114 introduced into the workflow. According tothe greater severity of the tracked state of shock of the patient 665,the patient agent 670 in combination with the patient agent 127communicates to the bidding engine 140 that the second patient 665 has ahigher priority status relative to the first patient 105. In response,step 675 includes the bidding engine 140 re-calculating or updating oraltering the bid values of the first patient 105 relative to the secondpatient 665 such that the broker 150 schedules the second patient 665 tobe seen by the physician 110 before the first patient 650. The type oftracked property (e.g., loss of consciousness, etc.) that would triggerthe second agent 665 to increase the priority status of the secondpatient 665 relative the priority status of the first patient 105 canvary.

As the agent 127 tracks an increase in the wait time of the firstpatient 105 to receive an examination by the physician 110, step 680includes the bidding engine 140 increasing the bid of the first patient105 relative to others that have less waiting time to receive anexamination by the physician 110. Step 685 includes the agent 127detecting and communicating that the wait time of the first patient 105to see the physician 110 has exceeded a threshold. In response, step 690includes the bidding engine 140 adjusting the bid of the first patient105 to exceed the bids of others waiting see the physician 110.According to the change in the bid of the first patient 105, the broker150 assigns the first patient 105 to be assigned the next available slotin the schedule of the physician 110 relative to other patients waitingto see the physician 110.

Step 695 includes receiving an examination and identifying or directingthe patient 105 to another resource 112 or 114. Assume that thephysician 110 identifies that degree of arterial blockage of the patient105 should be measured with the cardiac catheterization system 114. Step700 includes the agent 127 in combination with the bidding engine 140calculating a new bid of the first patient 650 for a slot in theschedule of the cardiac catheterization system 114 relative to bids ofother patients waiting for the cardiac catheterization system 114.Assume that upon increasing the bid of the first patient 105 withincreased waiting time relative to the other patients, the broker 150schedules the patient 105 in the next available slot in the schedule ofthe cardiac catheterization system 114.

Assume that examination by the cardiac catheterization system 114generates an output or report that quantifies an arterial blockage ofthe first patient 105 that requires an operative procedure. Step 710includes directing or identifying that the patient 105 is to be directedto the operating room 112 so as to receive the operative procedure toremediate the blockage. Now assume that the system 100 identifies thenew properties to tracked by the agent 127 relative to scheduling anopportunity in the schedule of the operating room 112 includes a waittime and the quantified blockage. Dependent on the tracked properties ofthe patient 105 relative to other patients, step 715 includescommunicating a priority status of the patient 105 to the bidding engine140, comparing the priority statuses received from the agent 127relative to others, and creating the bid of the first patient 105 for aslot in the schedule of the available operating room 112 relative toother patients scheduled or waiting for the operating room 112.

Step 720 includes the agent 124 of the operating room 112 detecting andcommunicating to the agent 127, or to the bidding engine 140, or to thebroker 150 that a time to wait for the operating room 112 exceeds athreshold (e.g., exceeding capacity, surgeon not available, exceedingthreshold wait time, etc.). Step 725 includes the broker 150 identifyingor calculating a next available option (e.g., wait in a cardiac careunit (not shown)) until step 730 of receiving the procedure in theoperating room 112 and/or completing the scheduled workflow.

FIG. 7 illustrates an embodiment of a dashboard 800 to illustrate outputdata of the system 100 shown in FIG. 1 and described above. Althoughdescribed with reference to the system 100, the dashboard can also bepart of the systems 300, 400, and 500 described above. The dashboard 800generally includes an illustration of each patient 105 admitted to theworkflow according to an order of value of bids 805 directed to each ofa series of slots 810 in the schedule of each of the available resources110, 112, 114 employed in executing the events of the workflow. Anillustration of the values of the bids 805 can also be listed, or thepatients 105 can merely be listed in numerical order of value of therespective bids. The dashboard 800 can further include a graphic displaygenerally illustrative of a geographic map 815 of the location,availability and current utilization of each of the resources 110, 112,114 that can be relative to a location of each patient 105. Theembodiment of the dashboard 800 can also include an alarm (e.g.,illumination of patient identification in a predetermined color, audiblealarm, etc.) indicative that respective agents 127 report that one ormore of the patients 105 exceeds a predetermined threshold (e.g., waittime) or is tracked to be in or approaching a predetermined criticalcondition (e.g., unconscious, threshold loss or increase in bloodpressure, cardiac arrhythmia, etc.). Any of the above-described trackedor calculated parameters can be illustrated in various combinations withone another at the dashboard 800.

FIG. 8 illustrates another embodiment of a dashboard 900 for graphicdisplay on a monitor or screen or other known similar device to anoperator. The dashboard 900 is generally configured to illustrate outputdata of the system 100 shown in FIG. 1 and described above. Althoughdescribed with reference to the system 100, the dashboard can also bepart of the systems 300, 400, and 500 described above. The dashboard 900generally includes an illustration of each of the value of bids 905generated by the bidding engine 140 for each of the one or more of theresources 110, 112, or 114 directed to each of a series of slots 910 inthe schedule workflow of each of the patients 105. As described above,the bidding engine 140 generates the bids dependent on received data ofthe tracked properties of the resources 110, 112, 114 (e.g., location ofresource relative to patient, failure condition, under repair orscheduled for maintenance after detected number of uses, dirty vs.clean, in current use, etc.) or patient 105. An illustration of thevalues of the bids 905 can be listed merely in numerical order of value.The dashboard 900 can further include a graphic display generallyillustrative of a geographic map 915 of the location, availability andcurrent utilization of each of the resources 110, 112, 114 that can berelative to a location of each patient 105. The embodiment of thedashboard 900 can also include an alarm (e.g., illumination of patientidentification in a predetermined color, audible alarm, etc.) indicativethat respective agents 127 report that one or more of the patients 105exceeds a predetermined threshold (e.g., wait time) or is tracked to bein or approaching a predetermined critical condition (e.g., unconscious,threshold loss or increase in blood pressure, cardiac arrhythmia, etc.).Any of the above-described tracked or calculated parameters can beillustrated in various combinations with one another at the dashboard900.

A technical effect of the above-described systems 100, 300, 400, and 500and methods 200 and 600 is to manage a workflow and respond to variouschanges in the properties of the resources (including patients) orworkflow in general real-time. Although the systems 100, 300, 400 and500 and methods 200 and 600 are described with respect to specifichealthcare environment, systems 100, 300, 400 and 500 and methods 200and 600 can be extended to any nature or type of workflow. Otherexamples include diagnostic equipment that supports multiple test typesreconfigures self to support high priority patient need. Alternatively,a department schedule can have one operational profile one day or evenone hour to suit a demand, and be reprogrammed with another operationalschedule to suit a different demand in time. The systems and methods arealso operable to create a schedule that accommodates combination orpermutations of conditions. Thereby, the systems and methods afford hugeflexibility and control of a workflow relative to those managed as onlya linear function.

Another technical effect of the above-described systems 100, 300, 400,and 500 and methods 200 and 600 to manage a workflow includes generatinga dynamic schedules based on dynamic properties of the resourcesinvolved in the process. In clinical workflows the dynamic propertiescan include a patient's current clinical condition and/or the staticconditions identified at admission through self/pre-assessments. Theabove-described systems 100, 300, 400, and 500 and methods 200 and 600are also operable cope with variance in patient wait time and processingtime relative to progression of tests and dynamic patient properties.

Another technical effect of the above-described systems 100, 300, 400,and 500 and methods 200 and 600 to manage a workflow is to facilitateenhanced management of workflows, generally in real time, where theworkflow might otherwise tend toward chaos due to complex conditionsthat evolve in general real time beyond the original workflow design.

Another technical effect of the above-described systems 100, 300, 400,and 500 and methods 200 and 600 to manage a workflow includes employinga_dynamic bidding process in general in general real-time to manage theworkflow. The above-described systems 100, 300, 400, and 500 and methods200 and 600 include defining dynamic properties, tracking theirproperties in real time, assigning a relative priority statusconsidering the properties of other resources or patients and biddingfor opportunities dependent on those priority statuses. The biddingpolicies can change dependent on, among other things, tracked propertiesof the various resources.

Yet another technical effect of the above-described systems 100, 300,400, and 500 and methods 200 and 600 an ability to manage the executionof the workflow in an adaptive manner. The above-described systems 100,300, 400, and 500 and methods 200 and 600 are operable to change variousevents/steps of the workflow in general real time based on the trackedproperties of the resources and patients in the workflow. For example,the above-described systems 100, 300, 400, and 500 and methods 200 and600 are driven by dynamic changes in capacity of the resources andconditions of the patients.

Another technical effect of the above-described systems 100, 300, 400,and 500 and methods 200 and 600 includes an ability to change theoperational profile of the various resources such as medical equipmentinvolved in the workflow dependent on the properties of the patient orequipment. For example, the system 100, 300, 400, and 500 are operableto reconfigure diagnostic equipment that otherwise support multiple testtypes to instead support a high priority patient need, or to schedulepatients on a basis of expected test times or steps along in the testsequence.

Yet another technical effect of the above-described systems 100, 300,400, and 500 and methods 200 and 600 is to measure and increase athroughput of patients through a department or unit dependent on changesin the equipment, procedure, patient population and so on. Yet anothertechnical effect of the above-described systems 100, 300, 400, and 500and methods 200 and 600 is extending capacity by adding similar systemsin real time dependent on the tracked capacity of and load to be handledby the resources 110, 112, 114 at the given point in time.

Yet another technical effect of the above-described systems 100, 300,400, and 500 and methods 200 and 600 include an ability to testpermutations or simulations in response to the dynamic properties of thepatient population relative to need for service.

Yet another technical effect of the above-described systems 100, 300,400, and 500 and methods 200 and 600 includes providing an ability toemploy a real time bidding techniques to manage a workflow, includingdefining dynamic properties to each bidder, tracking their properties inreal time, assigning a relative priority status considering theproperties of other resources, and bidding for an opportunity basedpriority status. To resolve the priority status or to assign theopportunity, a set of bidding policies are implemented dependent onstatic and dynamic properties of the patients and resources in theworkflow at a given time.

Although the subject matter is described herein with reference tomedical diagnostic or cardiac treatment applications, it should be notedthat the subject matter is not limited to this or any particularapplication or environment. Rather, the subject matter may be employedor applied to any service provider to manage scheduling of multi-variantor non-linear workflows. Examples include workflows employing anultrasound diagnostic system, on-line trading wherein buyers and sellerskeep on adding and removing from the process, supermarkets, ambulatoryor other emergency service, etc. Also, it should be understood that oneor more of the steps or components of one of the systems 100, 300, 400,and 500 and methods 200 and 600 and dashboards 800 and 900 describedabove can be used with another of the method or systems or dashboardsdescribed above and is not limiting on the disclosure.

This written description uses examples to disclose the subject matter,including the best mode, and also to enable one skilled in the art tomake and use the disclosure. The patentable scope of the subject matteris defined by the following claims, and may include other examples thatoccur to those skilled in the art. Such other examples are intended tobe within the scope of the claims if they have structural elements thatdo not differ from the literal language of the claims, or if theyinclude equivalent structural elements with insubstantial differencesfrom the literal languages of the claims.

What is claimed is:
 1. A method to assign a plurality of resources topatient progressing through a workflow of events, comprising: tracking afirst property of a first resource using a first agent; tracking asecond property of a second resource using a second agent; calculating afirst set of bids for the first and second resources based on therespective first and second properties, the first set of bidsrepresentative of priority statuses of the respective first and secondresources to a slot in the workflow of events; assigning one of thefirst resource or the second resource to the slot in the workflow ofevents based on the first set of bids; introducing a third resource andtracking a third property of the third resource using a third agent;calculating a second set of bids for the first, second and thirdresources based on the respective first, second and third properties,the second set of bids representative of priority statuses of therespective first, second and third resources to the slot in the workflowof events; reassigning one of the first resource, the second resource orthe third resource to the slot in the workflow of events based on thesecond set of bids.